@maiqueb: This pull request references CORENET-6005 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.21.0" version, but no target version was set.

Hello @maiqueb! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

/jira refresh

@maiqueb: This pull request references CORENET-6005 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target either version "4.21." or "openshift-4.21.", but it targets "openshift-4.20" instead.

/jira refresh

@maiqueb: This pull request references CORENET-6005 which is a valid jira issue.

@maiqueb Is there a reason this is currently only being tested on one variant?

@maiqueb Is there a reason this is currently only being tested on one variant?

Hey @JoelSpeed o/

Yes, and a good one - this feature is only supported on bare-metal. Hence, no point in testing it in other platforms.

/retest verify-feature-promotion

@maiqueb: The /retest command does not accept any targets.
The following commands are available to trigger required jobs:

/test build

/test e2e-aws-ovn

/test e2e-aws-ovn-hypershift

/test e2e-aws-ovn-hypershift-conformance

/test e2e-aws-ovn-techpreview

/test e2e-aws-serial-1of2

/test e2e-aws-serial-2of2

/test e2e-aws-serial-techpreview-1of2

/test e2e-aws-serial-techpreview-2of2

/test e2e-azure

/test e2e-gcp

/test e2e-upgrade

/test e2e-upgrade-out-of-change

/test images

/test integration

/test lint

/test minor-e2e-upgrade-minor

/test minor-images

/test okd-scos-images

/test unit

/test verify

/test verify-client-go

/test verify-crd-schema

/test verify-crdify

/test verify-deps

/test verify-feature-promotion

The following commands are available to trigger optional jobs:

/test okd-scos-e2e-aws-ovn

Use /test all to run the following jobs that were automatically triggered:

pull-ci-openshift-api-master-build

pull-ci-openshift-api-master-images

pull-ci-openshift-api-master-integration

pull-ci-openshift-api-master-lint

pull-ci-openshift-api-master-minor-e2e-upgrade-minor

pull-ci-openshift-api-master-minor-images

pull-ci-openshift-api-master-okd-scos-e2e-aws-ovn

pull-ci-openshift-api-master-okd-scos-images

pull-ci-openshift-api-master-unit

pull-ci-openshift-api-master-verify

pull-ci-openshift-api-master-verify-client-go

pull-ci-openshift-api-master-verify-crd-schema

pull-ci-openshift-api-master-verify-crdify

pull-ci-openshift-api-master-verify-deps

pull-ci-openshift-api-master-verify-feature-promotion

/test verify-feature-promotion

@maiqueb And its only supported on dual stack? Or also single?

@maiqueb And its only supported on dual stack? Or also single?

It should be on all networking configurations. We chose to deploy it only on dual-stack since that configuration is more flexible, and we get to check all types of UDNs in it (single stack IPv4 ; single stack IPv6 ; dual-stack).

At the end of the day, that is the "subject" under test.

Could you please also add testing on the two single stack variants, so we have complete coverage?

Could you please also add testing on the two single stack variants, so we have complete coverage?

@tssurya FYI

Could you please also add testing on the two single stack variants, so we have complete coverage?

Our QE @asood-rh should be doing v4 and v6 singlestack and dualstack on their side as well - we were trying to have less duplication between devel and qe on platform support resources wise but adding this might also help QE in some sense. So I don't mind having it in our ocp CI (not just qe CI). Although our baremetal CI resources are always limited so for each networking feature we seem to be adding new lanes for each feature level which is going to blow up at some point:

Example:
for BGP we did:

1. e2e-metal-ipi-ovn-dualstack-bgp-local-gw
2. e2e-metal-ipi-ovn-dualstack-bgp

For this feature we did:

1. e2e-metal-ipi-ovn-bgp-virt-dualstack-techpreview - which will GA
2. ipv4 variant - todo based on request
3. ipv6 variant - todo based on request

In the past for persistentIPs we did:

1. e2e-aws-kubevirt-ovn-techpreview - https://github.com/openshift/release/pull/65092/files
2. e2e-aws-ovn-virt-periodic - maybe this is same but periodic? - are these jobs still running @maiqueb ?

For L3 live migration @qinqon added a hypershift-kubevirt which always perma fails and not sure if there are periodics for this

So +1 for all stack coverage just want to highlight we might need to perm/combo choose a subset or consolidate all VM features into a single lane for cost-save rather than adding a virt lane per feature OR put all bgp features into a single lane

For L3 live migration @qinqon added a hypershift-kubevirt which always perma fails and not sure if there are periodics for this

@tssurya at hypershift kubevirt we have already periodics running on azure that test L3 live migration.

https://prow.ci.openshift.org/view/gs/test-platform-results/logs/periodic-ci-openshift-hypershift-release-4.21-periodics-e2e-azure-kubevirt-ovn/1965988883430641664

Our QE @asood-rh should be doing v4 and v6 singlestack and dualstack on their side as well - we were trying to have less duplication between devel and qe on platform support resources

Testing should default to on the public side of things now. There are various reasons we historically had private QE testing, but for new stuff, we should always aim for public testing reporting into sippy. Without data going into sippy we cannot manage regressions across the product.

Although our baremetal CI resources are always limited

Are there ways that the same clusters can be used to test these various features serially, so that we don't spin up a new suite for every feature?

@JoelSpeed so we need 4 new lanes right ? 2 (TP and GA) for single stack ipv4; same for ipv6

so we need 4 new lanes right ? 2 (TP and GA) for single stack ipv4; same for ipv6

@maiqueb That sounds correct.

Our QE @asood-rh should be doing v4 and v6 singlestack and dualstack on their side as well - we were trying to have less duplication between devel and qe on platform support resources

Testing should default to on the public side of things now. There are various reasons we historically had private QE testing, but for new stuff, we should always aim for public testing reporting into sippy. Without data going into sippy we cannot manage regressions across the product.

ack that's good to know! Is this also captured on our FG docs?

Although our baremetal CI resources are always limited

Are there ways that the same clusters can be used to test these various features serially, so that we don't spin up a new suite for every feature?

yes I believe its possible to consolidate instead of doing a new job per feature.

@JoelSpeed in hindsight, we've just realized this feature is not supposed to work for IPv6 single stack clusters.

It is clearly listed in the merged openshift enhancement: https://github.com/openshift/enhancements/pull/1793/files#diff-68747e5623b9c43b40b99e813c2acd3d642f58de610cfac6025699c66f062eeaR106

Thus, I think we should only add single stack IPv4 lanes. Would that be OK ?
Adding @kyrtapz to "back me up", and hoping he can add more motivation.

@JoelSpeed in hindsight, we've just realized this feature is not supposed to work for IPv6 single stack clusters.

It is clearly listed in the merged openshift enhancement: https://github.com/openshift/enhancements/pull/1793/files#diff-68747e5623b9c43b40b99e813c2acd3d642f58de610cfac6025699c66f062eeaR106

Thus, I think we should only add single stack IPv4 lanes. Would that be OK ?

+1
While having coverage for all possible setups would be ideal we don't want to consume too much of the available metal infra so having a dual-stack lane with BGP enabled us to test the the most scenarios. I am cool with adding a single-stack v4 as this would likely be the most popular deployment.

in hindsight, we've just realized this feature is not supposed to work for IPv6 single stack clusters.

It is clearly listed in the merged openshift enhancement: https://github.com/openshift/enhancements/pull/1793/files#diff-68747e5623b9c43b40b99e813c2acd3d642f58de610cfac6025699c66f062eeaR106

To clarify further - that means the usage of this feature is unsupported in that environment? How are we planning to make customers aware of that? If the feature is attempted to be used in an IPv6 single stack cluster, what happens?

Testing looks like it is on the right track. We have the lanes we need and most of the runs we need.

Is there a particular reason why some of the tests have 14 runs in dual and some only have 7?

Yes - we've added extra tests approx one week ago. These still have to catch up. One more round of gangway-cli and we should be good to go.

/test verify-feature-promotion

@everettraven / @JoelSpeed we've got sufficient coverage in the supported platforms (metal single stack ipv4 & metal dual stack).

Any chance of overriding the feature promotion job + hand out the required labels ?

Feature is only supported on baremetal ipv4 and dualstack variants. Sufficient automated regression testing is present for both platforms.

/override ci/prow/verify-feature-promotion

/lgtm

/verified by verify-feature-promotion

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aws-ovn
/test e2e-aws-ovn-hypershift
/test e2e-aws-ovn-hypershift-conformance
/test e2e-aws-ovn-techpreview
/test e2e-aws-serial-1of2
/test e2e-aws-serial-2of2
/test e2e-aws-serial-techpreview-1of2
/test e2e-aws-serial-techpreview-2of2
/test e2e-azure
/test e2e-gcp
/test e2e-upgrade
/test e2e-upgrade-out-of-change

@everettraven: This PR has been marked as verified by verify-feature-promotion.

@everettraven: Overrode contexts on behalf of everettraven: ci/prow/verify-feature-promotion

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: everettraven

The full list of commands accepted by this bot can be found here.

The pull request process is described here

/retest-required

Remaining retests: 0 against base HEAD 5d856d3 and 2 for PR HEAD ec8539c in total

/retest-required

/retest-required

Remaining retests: 0 against base HEAD 44baf88 and 1 for PR HEAD ec8539c in total

/retest-required

/retest-required

Remaining retests: 0 against base HEAD 3856d77 and 0 for PR HEAD ec8539c in total

/hold

Revision ec8539c was retested 3 times: holding

@maiqueb: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Full PR test history. Your PR dashboard.

Copying #2496 (comment)

Feature is only supported on baremetal ipv4 and dualstack variants. Sufficient automated regression testing is present for both platforms.

/override ci/prow/verify-feature-promotion

/hold cancel

@JoelSpeed: Overrode contexts on behalf of JoelSpeed: ci/prow/verify-feature-promotion

/cherry-pick release-4.20

@ormergi: #2496 failed to apply on top of branch "release-4.20":

Applying: network, virt: graduate preconfigured UDN addresses feature gate
Using index info to reconstruct a base tree...
M	features.md
M	features/features.go
M	payload-manifests/featuregates/featureGate-Hypershift-Default.yaml
M	payload-manifests/featuregates/featureGate-SelfManagedHA-Default.yaml
Falling back to patching base and 3-way merge...
Auto-merging payload-manifests/featuregates/featureGate-SelfManagedHA-Default.yaml
CONFLICT (content): Merge conflict in payload-manifests/featuregates/featureGate-SelfManagedHA-Default.yaml
Auto-merging payload-manifests/featuregates/featureGate-Hypershift-Default.yaml
CONFLICT (content): Merge conflict in payload-manifests/featuregates/featureGate-Hypershift-Default.yaml
Auto-merging features/features.go
Auto-merging features.md
CONFLICT (content): Merge conflict in features.md
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0001 network, virt: graduate preconfigured UDN addresses feature gate